home *** CD-ROM | disk | FTP | other *** search
/ The Atari Compendium / The Atari Compendium (Toad Computers) (1994).iso / files / umich / utils / maxidi22.lzh / MAXITECH.DOC < prev    next >
Text File  |  1992-06-05  |  14KB  |  267 lines
  1. ;File name:    MAXITECH.DOC        Revised:    1992.06.05
  2. ;Created by:    Ulf Ronald Andersson    Created:    1992.02.07
  3. ;
  4. ;File purpose:    To document the release of 'Revised MaxiDisk 2.0',
  5. ;   - " -    and provide some deeper details than MAXIDISK.DOC does.
  6. ;
  7. ; Copyright:    Original released as PD FREEWARE by author:  Max Böhm  1987.
  8. ;         Revisions as PD FREEWARE by author: Ulf Ronald Andersson  1992.
  9. ;        
  10. ;
  11. ; As may be apparent from the general layout of this text, most of it had its
  12. ; origin in my source-file comments for MAXIDISK.S, and its support files.
  13. ; Some of this information will of course duplicate that in MAXIDISK.DOC,
  14. ; but much of it is found in this file only, since I believe that few users
  15. ; of MaxiDisk will care very much how it works, as long as it is reliable.
  16. ;
  17. ;
  18. ;    Revision 2.2 updates of May 1992:
  19. ;
  20. ;    1. The routine that searches for the MPB pointers of TOS has been
  21. ;       improved, and now functions on all known TOS versions.
  22. ;
  23. ;    2. Some sector handling routines have been improved, though this
  24. ;       may be masked by the delays caused by packing.
  25. ;
  26. ;    3. MaxiDisk 2.2 has been tested error-free on several TOS versions
  27. ;       ranging from TOS 1.0 through TOS 1.4 to KAOS 1.4.2.
  28. ;       Since no TOS-dependent features are used it should always work.
  29. ;
  30. ;       Note, however, that COPY.TTP may fail on some ancient TOS's,
  31. ;       because of the bug in the gemdos function 'Malloc'.
  32. ;       Such failure only means that some files will be left uncopied.
  33. ;
  34. ;       Unfortunately the present release of TOS 2.6 has a bug in the
  35. ;       code for 'warm' reset, such that no reset-proof ramdisk seems
  36. ;       to be possible under this TOS !!!  (I will investigate this)
  37. ;
  38. ;
  39. ;    Revision 2.1 updates of March 1992:
  40. ;
  41. ;    Several routines were trimmed for higher efficiency, and one byte
  42. ;    in the simulated 'boot' sector was adjusted.
  43. ;
  44. ;
  45. ;    Summary of changes from old MaxiDisk to Revised Version 2.0:
  46. ;    ------------------------------------------------------------
  47. ;
  48. ;
  49. ;    1. I have implemented the XBRA protocol for all 3 vectors used.
  50. ;       This was one of the two reasons I made this revision.
  51. ;       The affected vectors are:
  52. ;       1) hdv_bpb        called by OS to identify disk format
  53. ;       2) hdv_mediach    called by OS to detect media changes
  54. ;       3) hdv_rw        called by OS for all read/write functions
  55. ;       During boot MaxiDisk checks if phystop points to the legal
  56. ;       identification code for MaxiDisk, which means warm boot.
  57. ;       But regardless of whether a warm or cold boot is indicated,
  58. ;       all 3 XBRA chains are tested to see if any XBRA named "MAXI"
  59. ;       is already in use.  If so, no new vectors are installed, and
  60. ;       an error message is given stating this situation.
  61. ;
  62. ;    2. I have modified the memory protection method, so that MaxiDisk
  63. ;       now is compatible with OVERSCAN.PRG and other programs that
  64. ;       previously could crash MaxiDisk (especially when nearly full).
  65. ;       (OVERSCAN.PRG must be started after MaxiDisk to function well)
  66. ;       The need to use it with OverScan etc., was of course my other
  67. ;       main reason to make this revision (by now practically rewrite).
  68. ;       This modification consists of several parts.
  69. ;       1) _memtop is adjusted in addition to phystop
  70. ;       2) the RAM block reserving high RAM is shrunk, and then released
  71. ;             using normal Mfree, so no garbage MPB's remain.
  72. ;       3) All data between _memtop and phystop is moved down into the
  73. ;          new corresponding area, without assumptions about screen size.
  74. ;       4) _v_bas_ad is adjusted without assuming either any screen size
  75. ;          or identity with _memtop, only that it lies somewhere between
  76. ;          _memtop & phystop, and the move will be a multiple of 512.
  77. ;          The move is not made direct in hardware, nor by calling XBIOS,
  78. ;          nor by poking _v_bas_add.  I simply store the new value in the
  79. ;          'screenpt' variable and await a VSYNC. Any screen handler which
  80. ;          has the physical screen in some other, immovable, area need
  81. ;          only ignore 'screenpt', so hopefully most large screens are OK.
  82. ;       5) A (hopefully) TOS independent routine searches all of OS RAM
  83. ;          to find the MPB root pointers enabling most of the above.
  84. ;          Should it fail, an error message will be given.  This does
  85. ;          NOT have to mean TOS incompatibility.  It may be due to some
  86. ;          earlier boot program messing with MPB's or _memtop, so do try
  87. ;          rearranging the auto folder in such cases.
  88. ;
  89. ;    3. I have patched the BPB handling to ensure better efficiency
  90. ;       when using huge ramdisks, which old MaxiDisk hardly packed.
  91. ;       BPB is still non_standard, of course, in that it has as many
  92. ;       logical clusters as there are physical sectors, but that is
  93. ;       how packing was made transparent to the OS.
  94. ;       Internally MaxiDisk uses linked packed data blocks of free size,
  95. ;       so the loss of space due to cluster size never occurs.
  96. ;       The packing itself also makes RAM storage more efficient, so that
  97. ;       the extra clusters' FATs originally marked BAD can be released,
  98. ;       simply by marking these clusters as FREE in the FAT sectors.
  99. ;       But to do so the FAT sectors and internal data block pointers
  100. ;       must be dimensioned to handle more data than the physical size.
  101. ;
  102. ;    4. I have completely rewritten the data block allocation code.
  103. ;       The original seemed to be compiler-generated rubbish.
  104. ;       It did work, but inefficiently, so I replaced it with a better
  105. ;       routine of my own design.  The main task it accomplishes is
  106. ;       to reclaim blocked ram by fusing released data block chains
  107. ;       into the chain of free blocks.  But the old routine did not 
  108. ;       always succeed in also fusing all adjacent blocks, so as to make
  109. ;       larger contiguous data blocks, and releasing some block links.
  110. ;       The new routine always does this, so whenever you clean out all
  111. ;       files from MaxiDisk, the data blocks all fuse into one huge block.
  112. ;       Thus you can always start over without any remaining fragmentation.
  113. ;
  114. ;    5. I have completely rewritten the pack/unpack routines, and have
  115. ;       changed the packing algorithm a bit. This makes packing a bit
  116. ;       tighter and faster, although no packing ramdisk can be FAST.
  117. ;       At present the new MaxiDisk seems to run at one eigth the speed
  118. ;       of QWIKDISK, as measured by QINDEX, which will do for me.
  119. ;       To be specific, each two-byte packing code, can now represent
  120. ;       a sequence of up to 64 bytes instead of the original 63 bytes.
  121. ;       Nonpacked sequences are limited to 128 bytes instead of 127.
  122. ;       A special marker has been implemented to allow completely
  123. ;       nonpacked sectors, used whenever packing proves inefficient.
  124. ;       So regardless of data complexity, you always have room for at
  125. ;       LEAST so much data as is presently indicated by the free FATs.
  126. ;
  127. ;    6. I have eliminated a lot of compiler-generated garbage-code, and
  128. ;       unneeded huge file arrays (that have NEVER been used !!!).
  129. ;       Also the insane program startup sequence, which turned the data
  130. ;       and BSS sections upside-down.  (Really...!)
  131. ;
  132. ;    7. I have also patched and streamlined each and every routine that
  133. ;       remains in the program to get rid of that silly compiler stuff.
  134. ;       eg:    "LEA    (A0),A0"  and such-like ridiculous nonsense.
  135. ;
  136. ;    8. I have added a simulated "boot" sector, since that area contains
  137. ;       the information which OS floppy routines use to boot their BPB's.
  138. ;       Programs that circumvent GEMDOS sometimes access this data,
  139. ;       instead of using BIOS Getbpb. Such programs will not work with
  140. ;       ANY RAM disk which do not initialize this area.  MaxiDisk now
  141. ;       sets the "boot" sector according to its current size in RAM, this
  142. ;       has been tested with MemFile 3.0 which can now access MaxiDisk
  143. ;       through the sector editor, something not possible before.
  144. ;
  145. ;    9. I have amended the 'hdv_mediach' routine to flag '1' on each call
  146. ;       that occurs directly after MaxiDisk has altered the allocation of
  147. ;       free FAT's. This flag is returned only on each first such call.
  148. ;       Its purpose is to force any programs that try to preallocate FAT's
  149. ;       to recognize the need to read the FAT sectors again.  This